Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_0399/302

Internet Message Format | 1994-08-27 | 8.9 KB

Subject: Digestive
Date: Sun, 5 Jun 1994 23:20:48 +0200 (MDT)
From: [e-mail] (Annius Groenink)
X-Face: "E3Hm]k]&:,OEP<{D2ixJf>-9[qOGLebNa0&cQyFL-a~)kTM3&&I"gFw=fJ]K%1IduGjOE`
 ZGu]&~G]QNGa7i/L!+#Xng<|+}HKYHj~5?fTInUEUh0$I1gBI7jrA!&_|e/pR1[cX:^xgJTPsrjA_9
 m8Zli[|.-u{]+c1(6C7mL*m`/_J\>.{4!:g
Mime-Version: 1.0
Precedence: bulk


I discovered  'split' on my  UNIX box,   and managed  to sz  the 70K  of
gem-list I received today home over the phone line.

------------------------------------------------------------------------

   [> Perhaps we should do this:
   [>
   [>     <-        Lshift
   [>     ->        Rshift
   [>         (uparrow)    Either shift

   Well, I do make a distinction in MasterBrowse (using exactly the method
   outlined above) but upon reflection I think it would be better not to
   make a distinction.  When typing, people ussually use the closest shift
   key to the key they want to press, so forcing them to use one key or
   the other might not be desirable.

I think we should include the option in the proposal with the additional
note that it should  only be used  rarely and there  should be a  pretty
good reason (for example something with left and right versions).

---

Tim writes

   Initially, I thought that I might be able to tolerate looking at the
   scancode for the control-keys, but with all this extra CRAP that needs to
   be dealt with for foreign keyboards, my responce is 'screw it!'.

   Hey, people, you're getting overly complicated!

This is a technical discussion,  Tim.  We're not afraid of details here,
be they of psychological nature or whatever.  A demanding user (such  as
yourself!) will not tolerate  a programmer  who doesn't go  to the  very
extreme to make his/her creations perfect.

I don't have a foreign keyboard either :-)  [it's a UK type] but I still
care (not least because Germany is a good Atari market).

---

Andre, wittily,

   (timothy)

   > When the simple solution would be to change select-whole-document to
   > something else on the keyboard... end of story.

   If SHORTCUT.INF becomes a reality, you will be able to do exactly that.

... except, probably,  in Atari Works...

---

Timothy:

   What do you suggest that the programmer do to distinguish between, some
   control codes (like ctrl-m, i, h, etc.) and the other keys that normally
   generate them (return, tab, backspace, etc.), and maintain compatibility
   with foreign keyboards?  Keep a seperate key table for each language?

The keytbl() command gives you the key tables.  It produces different
tables for different ROMs.

   If the shortcuts are configurable, then there's no point in having a
   standard because people can set it to however they want.  Programmers and
   users both would be changing them to their own preference, and no two

   systems would be the same.

The standard  would  be  a  way  of  distributing  a  STANDARD  shortcut
configuration,  and my guess is it will resemble the de facto  standards
pretty much so people won't change the very global shortcuts.

BTW,  we could easily distribute TWO standard configurations:  one  with
the german  ^U/^W and  one with  the  Motif standard  and ^W  for  close
window.   Perhaps  we  should  pipe  the  SHORTCUT.INF  through  the   C
preprocessor first (like .Xdefaults) and have a #define GERMAN.

Once we've settled a syntax,   we can continue the shortcuts  discussion
in that syntax,  which will avoid ambiguous proposals.

---

andre:

   Oh, am I allowed to see what you have decided to do to my proposals at that
   stage, then? That's very generous of you.

I agree,  it was a rather brute proposal of mine.  But then,  I tried to
get one discussion off the list for a while.  I thought I'd noticed that
people liked the .Xdefaults-like notation,  so I thought let's have a go
at that.  By the time I wrote that I didn't know you were going to write
a proposal the very same day.

   I think I've covered that already. What we could do is to allocate
   blocks of numbers for very specific tasks, such as DTP, MIDI, etc.
   Would that make you happier? (e.g. 1000+ for DTP-oriented tasks, 2000+
   for MIDI, 3000+ for painting/photo/etc, 4000+ for Database, etc).  Again
   I wanted to avoid making this too complex - if it's hell to work with, no
   one will bother.

Who's talking  about  NUMBERS?  Who's making  things  complicated  here?
Although I do agree that many people find files like .Xdefaults hard  to
maintain.  But making it case-insensitive already helps a bunch.

   The whole *idea* was to generate a file along the lines of ASSIGN.SYS, but
   with multi-language (optional) comments to allow users to change it if they
   want - or, as others have said, just use an editor.

The idea of a file came shortly after I proposed a system-wide  manager.
Sure,  a  file  seems  better,   but  why  ASSIGN.SYS  as  its  example?
ASSIGN.SYS is one of the most horrific file format's I've ever seen.

I re-read your first proposal,  but I still don't see what the actual
purpose of your codes is.  Do you have anything concrete in mind when
you say (still Andre:)

   The code numbers at the start of  each line would be defined as  part
   of our spec, and used by each  application to determine what type  of
   command is being defined on each line.

?

---

Michel:

   standard includes things such as block marking, what order modifiers
   should appear in menus, how dialog boxes should react to keys, and how
   the cursor should react to keys.  These are not things that can be
   controlled in the SHORTCUT.INF file.

I don't  see why  not.  Just  don't bind  keys to  MENU ITEMS,   but  to
descriptions of ACTIONS instead.  Such  an action could be  'select-all'
but it could equally well be 'delete-word'.

---

Tim:

   If,
   in order to support your standard, I have to go through a lot of work and
   headaches, I'm not going to support your standard.  I want to write a

   good piece of software and not sacrifice good functionality because I had
   to spend a lot of time dealing with unnecessary overhead.

Good point.  We should try and keep things simple.  The SHORTCUT.INF, if
it is ever to come,  should be designed to be

   a) easy to edit
   b) easy to parse,  with the sort of things a program uses it for in mind.

I am also slightly horrified  by the idea that I'd  have to match for  a
descriptive string  for  EVERY MENU  ITEM  or EVERY  ACTION  my  program
supports in order to process a line of the SHORTCUT.INF file...  This is
where a KEYMGR.ACC could  come in handy as  an intermediate between  the
SHORTCUT.INF file and the programmer.   A program would simply call  the
manager with its name,   its application class and  a key.  The  manager
would return a simple code  (perhaps a 'long ascii' cookie) the  program
could easily work with.

Then again... if we  adopt the RSC  editing option,  I  find it  equally
hard to search the  menu for shortcuts and  then store them  somewhere.
You can't search the menu for every single key...

---

michel:

   Yes, I agree.  Since each application knows what it supports and what it
   does nto, it should only use the keyboard shortcuts for the general codes
   that it supports.

Then we should allow  multiple assignments to one  key in the  standard.
Otherwise we'd  get a  standard full  of word  processor codes  such  as
Italic and Delete Paragraph and programs in other classes wouldn't  have
any room left for their specialities.

Maybe we should then split the shortcuts into a group of keys which have
ONE meaning (such as close window, cycle, select all),  and a series  of
keys for which the programmer can choose between a number of options (at
most,  say,  3 per key,  which reasonably resemble eachother).

---

michel:

   I agree; codes are the way to go.  Parsing text is also a problem because
   the user might edit the file (perhaps changing words or changing the
   case of the text) and mess everything up.  Numbers parsing is more
   efficient anyway.

Parsing numbers may be more efficient  for a computer,  but not for  me!
But if you feel so generous as to write the SHORTCUT.INF editor for  us,
I won't complain.

---

Timothy (repeating a point for the nth tyime in reply to Warwick
         repeating a point of his for the kth time)

   So, what you're saying is that Pradip should scrap his whole method
   for handling blocks for the sake of saving ctrl-A?

   That's rediculous.

   You're sacrificing a whole section of the user interface and making him
   scrap it and rewrite it just to save ctrl-A.


I'd like to repeat Warwick's point here.  That was an ILL section of the
user interface,  as some of us agreed on earlier.


   When the simple solution would be to change select-whole-document to
   something else on the keyboard... end of story.


A.  We've reached the end of the story?  Good.


cu
--
Annius V. Groenink | E-mail: [e-mail]      |  Private & ZFC:
CWI, Kruislaan 413 | Room:   M233            |  P.O. Box 12079
1098 SJ Amsterdam  | Ext:    4077            |  NL 1100 AB Amsterdam
Netherland         | Phone:  [phone] |  Phone: [phone]